home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 18 / CU Amiga Magazine's Super CD-ROM 18 (1997)(EMAP Images)(GB)[!][issue 1998-01].iso / CUCD / Online / hsc / docs-source / features / prefs.hsc < prev    next >
Encoding:
Text File  |  1997-10-12  |  7.2 KB  |  176 lines
  1. <WEBPAGE chapter="hsc - Features - " title="Syntax Definition"
  2.          PREV="if.html"
  3.          NEXT="exec.html">
  4.  
  5. <P>Everything <hsc> knows about html, it retrieves from a
  6. file named <hsc.prefs> at startup. This file contains
  7. information about all tags, entities and icon entites.
  8. Additionally, some <A HREF="spcattr.html">special
  9. attributes</A> are set up there also.</P>
  10.  
  11. <P>The main advantage of this concept is that it's rather
  12. easy to add new syntax elements. For this task, the hsc tags
  13. <ln_deftag>, <ln_defent> and <ln_deficon> can be used.</P>
  14.  
  15. <H2><A NAME="default">Default Preferences</A></H2>
  16.  
  17. <P>It is a serious problem about html that no one can give you competent
  18. answer on the question <qq>Now which tags are part of html?</qq>. On the
  19. one hand, there is w3c, which you meanwhile can ignore, on the other
  20. hand, there are the developers of popular browsers, which implement
  21. whatever they just like.</P>
  22.  
  23. <P>The <hsc.prefs> coming with this distribution should support most
  24. elements needed for everyday use. This includes full html-2.0-support,
  25. tables, client-side image-maps and several elements only used by
  26. special browsers.</P>
  27.  
  28. <P>However, they are currently rather outdated and could need a major
  29. rework. This should come with one of the next releases.</P>
  30.  
  31. <H2><A NAME="search">Searching For The Preferences</A></H2>
  32.  
  33. <hsc> looks at several places when trying to open <hsc.prefs>:
  34. <UL>
  35.     <LI>the current directory
  36.     <LI>the directory specified in the environment variable <env_hscpath> 
  37.     <LI>the directory <CODE>PROGDIR:</CODE>, which is automatically
  38.         assigned to the same directory where the <hsc> binary resides
  39.         when <hsc> is invoked
  40. </UL>
  41.  
  42. <P>If it is unable to find <hsc.prefs> anywhere, it will abort with
  43. an error message.</P>
  44.  
  45. <P>If you want to find out where <hsc> has read <hsc.prefs> from,
  46. you can use <KBD><A HREF=":options.html#status">STATUS=VERBOSE</A></KBD>
  47. when invoking <hsc>. This will display the preferences used.</P>
  48.  
  49. <H2><A NAME="tags">Special Tags To Modify Syntax Definition</A></H2>
  50.  
  51. <$macro SPCTAG NAME:string/r TITLE:string/r>
  52. <H3><A NAME=(name)><(title)></A></H3>
  53. </$macro>
  54.  
  55. All the tags below should be used within <hsc.prefs> only.
  56. <SPCTAG NAME="defent" TITLE="Define an entity">
  57.  
  58. <P>This tag defines
  59. a new entity. The (required) attribute <CODE>NAME</CODE> declares the
  60. name of the entity, <CODE>RPLC</CODE> the character that should be
  61. replaced by this entity if found in the hsc-source and <CODE>NUM</CODE>
  62. is the numeric representation of this entity.</P>
  63.  
  64. <STRONG>Example:</STRONG> <TG>$defent NAME="uuml" RPLC="ΓΌ" NUM="252"</TG>
  65.  
  66. <SPCTAG NAME="deficon" TITLE="Define icon-entity">
  67.  
  68. <P>This tag defines
  69. a new icon-entity. The only (required) attribute is <CODE>NAME</CODE>
  70. which declares the name of the icon.</P>
  71.  
  72. <STRONG>Example:</STRONG> <TG>$deficon NAME="mail"</TG>
  73.  
  74. <SPCTAG NAME="deftag" TITLE="Define a tag">
  75.  
  76. <P>This tag defines
  77. a new tag, and is used quite similar to <ln_macro>, exept that a
  78. tag-definition requires no macro-text and end-tag to be followed.</P>
  79.  
  80. <STRONG>Example:</STRONG> <TG>$deftag IMG SRC:uri/x/z/r ALT:string ALIGN:enum("top|bottom|middle") ISMAP:bool WIDTH:string HEIGHT:string</TG>
  81.  
  82. <P>To fully understand the above line, you might also want to read the sections
  83. about <A HREF=":macro/attrib.html">attributes</A> 
  84. and <A HREF=":macro/flag.html">options</A> for tags and macros.</P>
  85.  
  86. <P>For those, who are not smart enough or simply to lazy, here are some
  87. simple examples, which should also work somehow, though some features of
  88. <hsc> might not work:</P>
  89.  
  90. <$source PRE>
  91. <$deftag BODY /CLOSE BGCOLOR:string>
  92. <$deftag IMG SRC:uri ALT:string ALIGN:string ISMAP:bool>
  93. </$source>
  94.  
  95. <H2>Why DTDs Are Not Supported</H2>
  96.  
  97. <P>DTD is short for Document Type Definition. One of the early
  98. concept of html was that the first line of a document should
  99. contain a line that tells which DTD has been used to create this
  100. document. This could look like</P>
  101.  
  102. <$source PRE><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"></$source>
  103.  
  104. <P>Browsers should read that line, obtain the DTD and parse the source
  105. according to it. The problem about DTDs: they are written in sgml. And
  106. the problem about sgml: It's awful. It's unreadable. It's a pure
  107. brain-wanking concept born by some wireheads probably never seriously
  108. thinking about using it themselves. Even when there is free code
  109. available to sgml-parse text.</P>
  110.  
  111. <P>As a result, only less browsers did support this. As it was rather
  112. easy to write a browser spiting on the sgml-trash, but simply parsing
  113. the code <qq>tag-by-tag</qq>, developers decided to spend more time on
  114. making their product more user-friendly than computer-friendly (which I
  115. really can understand).</P>
  116.  
  117. <P>These browsers became even more popular when they supported tags,
  118. which certain people liked, but were not part of DTDs. As DTDs were
  119. published by w3c, and w3c did not like those tags, they did not made
  120. it into DTDs for a long time or even not at all (which I really can
  121. understand, too).</P>
  122.  
  123. <P>This did somehow work until html-2.0. Several people (at least most
  124. of the serious w3-authoring people) did prefer to conform to w3c than
  125. use the funky-crazy-cool tags of some special browsers.</P>
  126.  
  127. <P>However, after html-2.0, w3c fucked up. They proposed the infamous
  128. html-3.0 standard, which was never officially released, and tried to
  129. ignore things most browsers did already have implemented (which not
  130. all of them were useless). After more than a year without any
  131. remarkable news from w3c, they finally canceled html-3.0, and instead
  132. came out with html-0.32.</P>
  133.  
  134. <P>Many people were very happy about html-0.32, as it finally was a
  135. statement after that many things became clear. It became clear that
  136. you can not expect anything useful from w3c anymore. It became clear
  137. that the browser developers had won. It became clear that no one is
  138. going to provide useful DTDs in future, as browser developers are too
  139. lazy to do that. It became clear that anarchy has broken out for html
  140. specifications.</P>
  141.  
  142. <$macro even-sgml>
  143.     even without reading three books about sgml and analysing
  144.     20 example sources
  145. </$macro>
  146.  
  147. So, as a conclusion, reasons not to use DTDs but an own format are:
  148. <UL>
  149. <LI>It's more readable, and users can change it easier, <even-sgml>.
  150. <LI>It has been easier for me to implement, <even-sgml>.
  151. <LI>One does not depend on w3c
  152. <LI>The format for <hsc.prefs> contains some information, which makes
  153.     is possible to for example evaluate image-sizes or strip tags with
  154.     absolute URIs. This is realised with special attribute modifiers
  155.     which have no equivalent in DTDs.
  156. </UL>
  157.  
  158. <P>And, if you take a look at the current activities of w3c
  159. (discussing a standard for frames or proposing XML) and browser
  160. developers (spending most of their time fixing security bugs or write
  161. the ultimate desktop interface for all computers ever), I consider
  162. this even more a reasonable decision.</P>
  163.  
  164.  
  165. <H2>Problems</H2>
  166.  
  167. <P>There is also a disadvantage of this concept: reading <hsc.prefs>
  168. every time on startup needs an awful lot of time. Usually, processing
  169. your main data takes shorter than reading the preferences. You can
  170. reduce this time, if you create your own <hsc.prefs> with all tags and
  171. entities you don't need removed. But I recommend to avoid this because
  172. you might have to edit your preferences again with the next update of
  173. <hsc>, if any new features have been added.</P>
  174.  
  175. </WEBPAGE>
  176.